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We propose an electronic payment protocol for typical customer-merchant relations which does not 
require a trusted (signed) payment descriptor to be sent from the merchant to the customer. Instead, 
the destination "account" number for the payment is solely created on the customer side. This 
eliminates the need for any encrypted or authenticated communication in the protocol and is secure 
even if the merchant's online infrastructure is compromised. Moreover, the payment transaction 
itself serves as a timestamped receipt for the customer. It proves what has been paid for and who 
received the funds, again without relying on any merchant signatures. In particular, funds and 
receipt are exchanged in a single atomic action. The asymmetric nature of the customer-merchant 
relation is crucial. 

The protocol is specifically designed with bitcoin in mind as the underlying payment system. 
Thereby, it has the useful benefit that all transactions are public. However, the only essential 
requirement on the payment system is that "accounts" are arbitrary user-created keypairs of a 
cryptosystem whose keypairs enjoy a homomorphic property. All ElGamal-type cryptosystems have 
this feature. For use with bitcoin we propose the design of a deterministic bitcoin wallet whose 
addresses can be indexed by clear text strings. 

Keywords: financial cryptography, online electronic payment protocol, payment scheme, homomorphic key- 
pairs, ElGamal, bitcoin, deterministic wallet, labeled wallet, offline anonymous merchant 



I. INTRODUCTION 

We first review the current best-practice for bitcoin 
payments in customer-merchant relations, discuss its ob- 
vious shortcomings under a reasonable threat model, and 
formulate a goal for improvement. 



A. Bitcoin 

The Bitcoin network was introduced as a peer-to-peer 
online currency in 2009 [1]. To prevent double spending, 
a peer-to-peer currency faces the problem of establishing 
mutual agreement across the entire network regarding 
the ownership of funds. Bitcoin solves this fundamen- 
tal problem by a so-called proof- of-work principle, which 
requires every node in the network to solve a compu- 
tationally hard challenge before that node's ownership 
data is accepted by other peers. This challenge is defined 
by bitcoin as partially inverting the cryptographic hash 
function SHA-256. Mutual agreement regarding owner- 
ship is recorded in an authenticated data structure called 
the blockchain. Data blocks in the chain record owner- 
ship updates (called transactions) rather than balance 
sheets. Each transaction is signed against the public key 
of the previous owner (the input of the transaction) and 
defines the public key of the new owner (the output). In 
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fact, the bitcoin system only deals with keypairs — the 
"owner" of a keypair becomes an irrelevant entity and is 
in no way recorded. Consequently, bitcoin does not rely 
on any public key infrastructure (PKI). One commonly 
refers to public keys as addresses, suggesting that they 
are the "location" of funds. Users hold collections of key- 
pairs, and such collections are called wallets. Currently, 
all keypairs for bitcoin belong to the ECDSA signature 
scheme (Elliptic Curve Digital Signature Algorithm) on 
the elliptic curve secp256kl [2]. 

This paper uses a homomorphic feature of keypairs, 
that ECDSA shares with all ElGamal-type signature 
schemes (see end of II C below for details) and would 
not be possible if bitcoin used RSA-type signatures. 
Conversely, bitcoin can be replaced in this paper by 
an abstract payment system that allows arbitrary user- 
generated account numbers which correspond to public 
keys of a cryptosystem with equivalent or similar homo- 
morphic features. For instance, the decentralized aspect 
and the proof-of-work principle of bitcoin play no role 
here. Other details of the bitcoin technology such as the 
script system are not essential for the main part of the 
paper but are addressed in the dedicated subsection II H. 



B. The customer-merchant relation 

A customer C has a device D (e.g. a desktop computer) 
to browse merchant websites and to place orders on those 
sites. D does not hold any bitcoin wallet files. Further- 
more, C interacts with a trusted path device T (e.g. a 
hardware wallet) to sign transactions. For this purpose. 
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T has access to the private keys of a bitcoin wallet. We 
assume T is never compromised. This assumption is jus- 
tified, e.g., in a scenario where T is securely booted, re- 
ceives data from D through an air gap, and has a one-way 
channel to broadcast signed transactions to the bitcoin 
network. 

A merchant M has a device VF, e.g. a server running 
a webshop, to receive and process orders. Processing an 
order requires at least to generate a payment address 
and to return it to the customer. For this purpose, M 
divides his bitcoin wallet in two parts, the address wal- 
let L and the key wallet. The address wallet is stored 
on W, whereas the key wallet is stored securely offline. 
The commonly implemented payment protocol for this 
standard scenario is depicted in Figure IB. 
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FIG. 1. Classic protocol for bitcoin payments in customer- 
merchant relations. (J) customer C with his desktop com- 
puter D browses the webshop W run by merchant M 
over a secure SSL connection. (2) C submits an order 
to the webshop. (3) W picks a payment address from a 
pool L of bitcoin addresses, which comprises the public 
part of a bitcoin wallet (green). The private part of the 
wallet (red) is stored offline. (4) The payment address is 
returned to D. (f) C signs a transaction to the payment 
address on his hardware wallet T. (6) C broadcasts the 
transaction to the bitcoin network. 



C. Signatures and merchant reputation 



This attack can - in principle - be prevented by intro- 
ducing signatures into the protocol. We assume that M 
has a private/public keypair (K, P) for which the public 
key P is known to C before the protocol starts. An obvi- 
ous choice for [K, P) would be the keypair on which M 
builds his reputation as a merchant, e.g. a Secure Sock- 
ets Layer (SSL) certificate. Conversely, however, we do 
not assume that M holds a public key of C before the 
protocol starts. 

Suppose A'l bundles the order (which we assume con- 
tains the delivery address) together with a payment ad- 
dress into a bill, signs the bill with K and returns the 
signed bill to C. For C this means that, if anything goes 
wrong, he can prove that the attack was launched on the 
merchant side and not on his side. For M, however, this 
means that signing the bill can not be done on W . The 
naive idea that M signs all addresses from the address 
wallet L ofSine and stores the pre-signed version of L on 
W is not sufficient. While it protects the funds well, it 
does not protect the goods since there is no way to pre- 
sign the delivery addresses. Generating addresses from 
so-called deterministic wallets (see II C for a definition) 
also does not help. 



D. The firewall solution 

In the "firewall solution" M stores the address wallet 
L and the private reputation key K on a separate, well- 
protected device S. We assume that S is linked to W 
via a channel that does not allow Ai to compromise S 
(firewall). After receiving and pre-processing the order, 
W forwards the order to S. Then S picks an address from 
i, signs address and order together into a bill, sends the 
signed bill to W who forwards it to D. For this purpose, 
S instead of W holds L and K. This protocol is depicted 
in Figure 2. 

While it is feasible for C to interact with a trusted path 
device, M wants S to run unattended. This raises two 
problems: The first problem is to implement a secure link 
between W and S. This may set off individuals and small 
businesses who do not have the required expertise. A 
second problem is to properly protect S physically. This 
may set off even mid-sized businesses who, on the one 
hand, have to replicate S in order to scale or to prevent 
denial-of-service attacks, and, on the other side, do not 
have the resources to protect all replications of S. 



We first focus on security of the merchant side. As 
a reasonable threat model, since W is connected to the 
Internet and is a publicly known webshop, we assume 
that W is compromised by an attacker Ai. Since the 
key wallet is offline, Ai cannot steal coins directly from 
M. However, Ai can tamper with the payment address 
and redirect Cs transaction to his own addresses. De- 
pending on the type of order, Ai may also tamper with 
other information in the order, e.g. a delivery address, 
and redirect goods instead of funds. 



E. Customer side security 

We now turn to the security of the customer side, as- 
suming that the device D is compromised by an attacker 
A2. Then A2 can play a man-in-the-middle attack be- 
tween M and C, e.g. submitting a false delivery address 
to M . Or, A2 can forward a false payment address to T. 
The only solution is to carry out the verification of the 
signed bill against the merchant's public key P on the 
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FIG. 2. Signature-based protocol with firewall, ©j® ^ 
before, (f) W passes the order across a firewall to device 
S. (4) Order and payment address are signed together 
with the private key (red key) of M, forming the bill. 
® The biU is returned to D. ® D verifies the bill's 
signature against the public reputation key (green key) 
of M. (7) C signs a transaction to the bill's payment 
address on his hardware wallet T. (s) C broadcasts the 
transaction to the network. 



key K on W, the protocol must be signature-less. This 
can only be achieved by moving the generation of the 
payment address to the customer side. 

The idea for such a protocol is not new. Customer- 
generated payment addresses are suggested in [3] , and [4] 
points out that they dispense with the need of encrypted 
or authenticated communication between customer and 
merchant. 



G. Anonymity 

We also discuss anonymity properties of our payment 
protocol. However, we disregard all issues arising from 
tracing payments via an analysis of the public transac- 
tion record. The same holds for other (non-payment) 
order-related information, that may be obtained via trac- 
ing shipments or downloads. In particular, it is not in 
the scope of this paper how the customer can retain his 
anonymity from the merchant. 

Just like with any protocol that creates a new payment 
address for every transaction, one can easily conceal that 
M is the addressee of a payment transaction (see II G). 
We discuss in further detail how the merchant can hide 
himself and all his infrastructure from the customer (sec- 
tion IV). This requires the merchant to operate under a 
pseudonym, which we assume is represented by the rep- 
utation key P. 



trusted device T rather than on D. In order to make this 
verification reliable, we assume that P is stored on T he- 
fore C places an order. However, even though T can ver- 
ify the bill's signature automatically, this does not mean 
that the whole verification process is automatic. Rather, 
in order to prevent A2 's man-in- the-middle attack, T has 
to display the whole bill and wait for an interactive con- 
firmation from the customer C . 

We remark that if D is compromised by A2 then C 
cannot rely on D to authenticate W , e.g. via the usual 
SSL/TLS authentication of the browser running on D. 
However, having the signature verification against P take 
place on T, this does not pose a problem. In fact, au- 
thentication between W and D is not necessary anymore. 

The assumption that P is stored on T before the pro- 
tocol starts is fundamental throughout the paper. Public 
key infrastructures (PKI) can solve the problem how C 
obtains P. A possible scenario is that hardware wallets 
are shipped with hard-coded root keys, just like browsers 
are shipped with root SSL/TLS certificates. This, how- 
ever, is not in the scope of this paper. 



F. Goal 

The goal is to devise a payment protocol that works 
without an additional secure device S on the side of the 
merchant. Since M cannot store the private reputation 



II. THE PAY-TO-CONTRACT PROTOCOL 

We first discuss the customers requirements regarding 
receipts in HA and formulate the pay-to- contract prin- 
ciple. Then, in II D, we devise a protocol adhering to 
this principle that does not rely on any form of trusted 
(signed) payment descriptor. 



A. Payment receipts 

After making a payment, C wants to be able to prove 

(i) that M has agreed to fulfill a given order upon re- 
ceiving a certain amount of funds, 

(ii) that a certain amount was paid to and received by 
M for that same order. 

In the traditional, paper based customer-merchant rela- 
tion (i) is accomplished by a hill, signed by M in advance, 
and (ii) by a receipt, signed by M in exchange for the 
funds. The receipt usually contains a reference to the 
bill. In fact, for an electronic payment protocol we sim- 
ply assume the receipt contains the bill — just as paper 
based receipts are usually kept stapled together with the 
corresponding bill by the customer. 
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More abstractly, the bill is a contract x signed by M 
alone, to which C enters by conducting the payment re- 
quired in a;. If a cryptographic hash of x can be attached 
to the transaction on the blockchain then this transac- 
tion proves (ii) . There are several known ways to attach a 
unique hash to a bitcoin transaction, e.g. by encoding the 
hash into one of the output addresses. We will system- 
atize such an encoding in II D below. Thus, with bitcoin, 
funds and receipt can be exchanged in an atomic action. 
Since the blockchain is public, the contract x proves both 
(i) and (ii), i.e. functions as bill and receipt. 



B. Pay-to-contract 

A payment descriptor for a contract x specifies the pay- 
ment that C has to conduct in order to enter x. It is a 
record, holding a payment address and an amount, that 
is signed by M with a reference to x. Alternatively, one 
can think of the payment descriptor as part of x and 
require that x is signed by M as a whole. 

The main point of this proposal is to eliminate pay- 
ment addresses from all payment descriptors, whether 
they are part of x or separate. Instead, we suggest that 
the payment address is derived deterministically from the 
contract itself, so that it can be computed by C alone 
and without any additional data. This is what we call 
the pay-to- contract principle and what achieves the goal 
formulated in I F. 

In detail, pay-to-contract works as follows: As in the 
setup of the introduction, K is the private key and 
P the public key that define the online reputation of 
M. Let 77 be a cryptographic hash function. Sup- 
pose we have a pair of functions daddr , o^priv such that 
diiddi{PT H{x)) is a bitcoin address unique for P and 
H{x), dpriviKjx) is the private key corresponding to 
rfaddr(-P, a^), and dpriviK,x) cannot be computed with- 
out K. If we define b := da,ddi {P, H{x)) as the payment 
address for x, then C can compute b with the information 
available to him and only M can access the funds on b. 

As an additional feature, x automatically serves as a 
receipt for C in the sense of II A. Since H{x) is encoded in 
the output address 6, the contract x is verifiably attached 
to the payment transaction [5]. 

A suitable address derivation function daddr can be 
obtained from deterministic wallets, as was previously 
noted in [3] , [4] . Before elaborating on the details (II E) , 
we recall the concept of a deterministic wallet (II C) and 
propose to standardize a certain type of deterministic 
wallet (II D). 



C. Deterministic Wallets 

A deterministic wallet is a sequence of bitcoin keypairs 
(i.e. addresses and their private keys) that are all derived 
from a single secret called the base of the wallet. For 



instance, the base can be a bitcoin keypair by itself, but 
this is not a requirement. 

Deterministic wallets greatly facilitate backups be- 
cause it suffices to back up the base. All keypairs can 
be recovered from the base by enumerating them. 

One further distinguishes two types of deterministic 
wallets [6]: In a type 2 wallet, one can derive from the 
base another secret that we call the pubhase. All ad- 
dresses can then be derived from the pubbase alone, but 
none of the private keys can. Type 1 wallets do not have 
this feature. All known type 2 wallets have the disadvan- 
tage that the base can be reconstructed from the pubbase 
and any one of the wallet's private keys, thus diminishing 
somewhat the usefulness of the pubbase. For type 1 wal- 
lets it is trivial to prevent this, i.e. to make the security 
of any of the wallet's private key independent from the 
security of the base. 

The separation of base and pubbase in type 2 wallets 
offers two significant benefits. First, there is a security 
benefit: a vulnerable device can store only the pubbase 
and derive addresses as they are needed, while the private 
keys can be derived independently on another device that 
holds the base. Second, it is possible to prove that a 
certain pubkey was derived from a given pubbase without 
revealing any private keys. 

Type 2 deterministic wallets are possible because from 
an ElGamal-type keypair (s, a) one can obtain a new key- 
pair {ns, na) by multiplication with any integer n (see [7] 
or sections 8.4, 11.5.2 in [8]). This is called a homomor- 
phic relation between private and public keys. Type 2 
deterministic wallets would not be so easily available if 
bitcoin used RSA signatures, for instance. 



D. Labeled Wallets 

By a labeled wallet we mean a (non-enumerable) set of 
bitcoin keypairs that are all derived from a single secret 
called the base of the wallet and that are indexed (relative 
to the base) by an arbitrary label. 

The difference between a labeled wallet and a deter- 
ministic wallet is that labels cannot be enumerated. To 
backup a labeled wallet it does not suffice to backup the 
base, one also needs to know the labels. 

Labeled wallets can mimic deterministic wallets by re- 
stricting the labels to some enumerated sequence. Con- 
versely, a deterministic wallet in which the enumerated 
keypairs can be accessed randomly can mimic labeled 
wallets by translating the label to a number via a hash 
function. 

The same distinction between type 1 and 2 can be 
made for labeled wallets as for deterministic wallets. We 
propose in the following to standardize a type 2 labeled 
wallet. To this end, we first fix i) an encoding for the 
labels (e.g. UTF-8), and ii) a cryptographic hash func- 
tion H (e.g. SHA-256) whose digests are interpreted as 
non-negative integers. The application of labeled wallets 
may not be restricted to the pay-to-contract principal. 



As a base for the labeled wallet we use an ECDSA 
keypair (s, a) for bitcoin's curve secp256kl [2], i.e. s is an 
exponent and a is the point where g is the base point of 
the curve. We call s the private base (or master private 
key) and a the pubbase (or master pubkey). The curve 
operation is written multiplicatively in order to better 
distinguish points from exponents (other people prefer 
to write a = s ■ g instead) . 

The derived keypair with label x of the wallet with base 
(s,a) is written (s[x],a[x]) and is constructed as follows. 
The label is an arbitrary string in the chosen encoding 
(e.g. X ='savingsl'). We define 



s\x\ := s - 



H{x), 



a ■ g 



(1) 



We call s[x] the derived private key and a[x] the derived 
pubkey. Obviously, the derived pubkey can be computed 
from a and x without knowledge of s. 

In order to apply labeled wallets to the pay-to-contract 
principle, we suppose that A'Ps keypair (K, P) is an 
ECDSA keypair for the same curve secp256kl. Then 
{K, P) can serve simultaneously as the base of a labeled 
wallet. In effect, M builds online reputation on a la- 
beled wallet. Functions daddr , t^priv that satisfy the re- 
quirements of II B are obtained by 



rfpriv(P,2:) K[x], d,M,{P,x) := Hash 1 60 (F [a;]). 



where Hashl60 is the bitcoin-defined 20-byte hash. 



(2) 



E. Basic protocol 

A pay-to-contract protocol using labeled wallets and 
address derivation (2) works as follows. Upon receiving 
an order from C's device D, device W generates a con- 
tract X and sends x back to D. 

The part of x that does not change on a order-by-order 
basis is called static. Static information may change in 
regular intervals that are convenient to M , usually span- 
ning several orders. For instance, M's terms of service 
and price list would be considered static. The part of x 
that changes on a order-by-order basis is called dynamic. 
All information given by D in an order, e.g. the item 
number, quantity and delivery address, is considered dy- 
namic. 

We assume that x contains the pubkey P, all static 
information is signed with K, and dynamic information 
is unsigned. Upon receiving x, device D checks if x is 
consistent with the order it intended to place, and, if 
so, forwards x to T. Then T verifies all signatures in- 
side X and displays P and x to C. When C interactively 
approves the contract, T computes b := da_ddr{P,x) and 
generates and broadcasts a transaction that sends the 
amount given in x to address b. Finally, T permanently 
stores X because the contract is simultaneously the re- 
ceipt for C. This protocol is depicted in Figure 3. 
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FIG. 3. Pay-to-Contract protocol. Merchant M 

signs price list and terms and conditions offline. Pre- 
signed versions plus M's public reputation key are com- 
piled into contract template, stored on webshop W. @- 
(5) as before. @ W fills order details into contract tem- 
plate, forms contract, (t) Contract returned to D. (§) 
C uses hardware wallet T to verify contract signatures. 
Contract's reputation key is looked up in pre-stored key- 
alias database, (g) T displays all contract details plus 
alias of reputation key. @) C manually approves con- 
tract details and identity of reputation key. @ T applies 
address derivation function to contract, obtains payment 
address. as before. 



F. Security 



Since C only approves a transaction if T displays an 
order x that C actually intends to place, the transaction 
will always go to the correct output address (iaddr(^', 2:). 
If an attack leaves W with a tampered version x' of 
X then M expects the payment at a different address 
daddr{P,x'). The rcsult will be that M never detects a 
payment to this address and never ships the order. When 
C submits the receipt a; to M via another channel to re- 
solve the matter (even publicly, in court), then M but 
only M can compute s[x] and redeem the output. 

Therefore, the attack possibilities of Ai , A2 are lim- 
ited to denial-of-service and messing with the tracking 
and inventory system that may run on W. It cannot be 
proved whether the attack happened on the customer or 
merchant side. 



6 



G. Summary of properties 

A few properties of the pay-to-contract protocol are 
worth being summarized: 

1. There is a unique address for each contract x and a 
pubhc proof of payment. Anyone who knows x can 
verify whether x was paid for or not. M cannot 
deny to have received a payment to (iaddr(^', a:). 

2. Third parties cannot necessarily monitor all incom- 
ing payments to M, because they would have to 
guess X. If X is properly randomized, e.g. if x con- 
tains a salt, then neither P{x\ nor daddr(-P, 2^) can 
be linked to the merchant via his public key P. 

3. The major part of the protocol can be carried out 
on untrusted devices {D and W). In particular, 
the communication link between D and W is not 
required to be secure (encrypted or authenticated) . 
Instead, it can be unencrypted email. 

4. C needs a trusted path device T with a display large 
enough to show all sensitive parts of the contract x. 
In particular, it cannot be a smart card, and single- 
line LCD displays also seem improper. 

5. C must have obtained P in advance, and must have 
stored P in a place where no attacker can tamper 
with it and from where C is able to compare P 
to what T displays. Of course, P can be stored 
on T itself, e.g. linked to an alias that is displayed 
instead of T. In this case, the binding of P to an 
alias can further be authenticated by a public key 
infrastructure (including web-of-trust). 

6. For repeated orders, C can create x all by himself 
with no direct interaction with M . Only after the 
transaction does C need to submit x to M . This 
feature is further used and explained in IV below. 

Authentication in this protocol is moved from the 
browser level (based on trust in SSL/TLS certificates) 
to the payment level (based on the trust in the key P). 
We remark that building online reputation (i.e. reputa- 
tion as a merchant) on a "payment base address" (such 
as P) is more universal than on SSL/TLS certificates. 
For example, a business may have a single payment base 
address but several websites under different top-level do- 
mains who would all require their own SSL/TLS certifi- 
cate. Moreover, certain scenarios (e.g. paying at point-of- 
sales, teller machines, etc.) may not involve any browser 
at all, leaving no other choice than to authenticate the 
payment address directly. 

H. Generalized Labeled Wallets 

We now discuss a bitcoin specific enhancement based 
on the so-called script system. In bitcoin, transaction 



outputs are more flexible than simple "account num- 
bers". Instead, they are stack-based scripts. An out- 
put can only be redeemed upon providing an input to its 
corresponding script such that, when run with this input, 
the script returns true. Due to the significantly improved 
security it provides, the so-called "multi-signature" script 
is becoming popular. It requires signatures for a thresh- 
old number of n public keys from a set of m specified 
public keys. Merchants likely want to receive funds di- 
rectly to multi-signature scripts, rather than to regular 
bitcoin addresses. 

Complicated scripts are often replaced by their hash in 
a special type of output called pay-to- script-hash (P2SII, 
[9]). This can be done with any script and does not affect 
the enhancement we are about to describe. 

As it turns out, the pay-to-contract protocol can be 
generalized in a straightforward manner to produce a 
wide array of script outputs. The idea is to define a 
base script in place of a base address. From this, one 
obtains derived scripts which can only be spent with the 
same knowledge required to spend the base script. The 
derivation process for label x replaces every pubkey P in 
the base script by the derived pubkey P[x] in the sense 
of II D. In this way, all scripts that contain explicit pub- 
keys and not their hashes can serve as base scripts. 

As an example, we look at a 2-of-2 multi-signature 
script: 

2 Pi Pa 2 OP_CHECKMULTISIG (3) 

where Pi,P2 are pubkeys. Using (3) as the base script, 
the derived script with label x is obtained by replacing 
each pubkey Pi with P^ [x\ : 

2 Pi[x] P2[x\ 2 DP_CHECKMULTISIG (4) 

For practical reasons, the customer then pays to the 
script hash address (P2SH) of (4), i.e. to: 

0PJ1ASH160 <addr> OP_EQUAL 

where <addr> is the 20-byte hash of (4). 

If the merchant wallet "base" is a script rather than 
a pubkey then it can obviously no longer be identical 
to the reputation key P. Instead, it should be signed 
by the reputation key and publishes via some public key 
infrastructure. 



I. Alternative definitions 

Alternatively to (1), we can set s[x\ :— s ■ H{x) and 
a[x\ := a^*^^' without changing any properties of the la- 
beled wallet nor any properties of the protocol. 
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III. STRUCTURE OF CONTRACTS 



Contract as Merkle trees 



IV. OFFLINE AND ANONYMOUS 
MERCHANTS 

A. Offline merchants 



In the pay-to-contract protocol, the contract x serves 
simultaneously as the payment descriptor and the re- 
ceipt. Its function as a receipt demands that C is able to 
partially reveal the contents of x. In the extreme case, C 
may only want to prove that a certain transaction made 
by him has an output that is controlled by M, while in 
other cases C may want to reveal what was paid for but 
not the delivery address. Therefore, x is structured in a 
Merkle tree and every node is salted. In order to hide 
the contents of a branch, it is replaced by its hash digest 
without making x invalid. 

The layout of the tree does not need to be standard- 
ized, its design can be left to M. However, we propose 
that at least the overall format of a contract as a JSON- 
encoded tree-object is standardized. 

Leaf nodes of the tree can further be encrypted with 
a public key that is specified in the contract layout. In 
this case, the hash of the ciphertext (not the cleartext) 
is used in the Merkle tree. Then C has the choice to 
reveal the cleartext, the ciphertext or the hash. As an 
application of encrypted contract fields, one can think of 
an entity that is handling contracts on behalf of M. This 
entity can receive the contract with encrypted fields, can 
verify that is has been paid for on the blockchain, and 
can pass it on to M, all without seeing the cleartext of 
the encrypted fields. 



B. Recommended fields of contracts 

Even though the tree layout is left to the merchant, 
it is advisable to make recommendations for the nam- 
ing of fields, in order to facilitate automatic verification. 
This can include a division into static and dynamic fields, 
depending on whether the field is changed on an order- 
by-order basis or not. It is recommended that static 
fields are signed with the merchant's online reputation, 
whereas dynamic fields are signed with another key that 
represents the merchant's online tracking and inventory 
system. 

A suggested list of dynamic data records is: item num- 
ber, quantity, price, delivery address, delivery deadline 
(timestamp or block number), payment address, pay- 
ment deadline (timestamp or block number), client's ref- 
erence/tracking token, merchant's reference/tracking to- 
ken. 

A preliminary list of static data records is: price, mer- 
chant's terms of service, warranty, name of merchant's 
auditors. Static data records should be pre-signed by the 
merchant before they are assembled into the contract. 



According to II G, point 6, the customer can order "of- 
fline" and pay in advance before informing M about it. 
For instance, if M sells digital (unlimited) goods for a 
publicly known price or simply receives donations then C 
has no need to communicate with M before the payment. 
Neither the order itself nor the pay-to-contract protocol 
require such communication. After the payment, C can 
redeem the contract x for the digital goods. This pro- 
tocol is depicted in Figure 4. It requires a public place 
for the announcements of "blank" contracts called con- 
tract forms. For practical purposes, all announcements 
from the merchant M should be tagged by the public 
reputation key of M. 



securely stored: 




> redeem contract ^AAAAA^ 
physical separation 




FIG. 4. Offline protocol @ Merchant M signs a contract 
form offline, containing price list, terms and conditions, 
expiration date. (5) M posts contract form in a pub- 
lic place (electronic or print), (s) Customer C retrieves 
contract form from public place. (?) C flUs order de- 
tails (item, quantity, delivery address) into contract form, 
forming a contract. (5)-@ as before. (Q) C redeems con- 
tract to webshop W via one-way channel. @i T applies 
address derivation function to contract, obtains payment 
address to monitor. 

The situation is different with physical goods because 
usually C wants to check with M first if the items are in 
stock. 

Granted that C knows M's reputation pubkey in ad- 
vance, the interaction between M and C in Figure 4 is 
reduced to a one-way communication from C to M (the 
redemption of x) . This means instead of running an inter- 
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active webshop, M only needs a channel to receive con- 
tracts (e.g. email). Going even further, customers can 
post their (encrypted) contracts in a public place from 
where M retrieves them. In this case there is no direct 
communication between C and M at all, neither for or- 
dering nor for paying, and we speak of A'l as an offline 
merchant. 

Being an offline merchant may help M to stay anony- 
mous from C, or may make M less prone to denial-of- 
service attacks. 



B. Anonymity 

An offline merchant M may want to stay anonymous 
and use his reputation key as a pseudonym. Moreover, M 
may want to hide as much of his activity from the public 
as possible. He therefore asks his customers to redeem 
their contracts by posting them in encrypted form to a 
public distributed filesystem. 

Then M is required to monitor the filesystem and to 
identify the contracts posted for him among all files. We 
assume it is infeasible for M to download and check every 
single file whether he can decrypt it or not. Therefore, 
the customers have to "tag" their posted files in some 
way as being addressed to M . But this is not easily pos- 
sible without revealing to the public that a certain file is 
addressed to M . Hence, naively using the above offline 
protocol may provide anonymity to M but leaks infor- 
mation such as the number of orders that M receives, 
their timing and contract sizes to any observer of the 
distributed filesystem. 

C. Goal and Achievement 

The goal is to devise a protocol that allows customers 
of an offline merchant to redeem contracts without dis- 
closing to an observing third party that a redemption has 
taken place. If this is achieved we speak of M as a fully 
anonymous merchant. 

We divide the protocol into two parts. First, the sig- 
naling protocol allows C to secretly share a unique integer 
value with M . By this we mean that only C and M get 
to know the value, while any third party can not even tell 
that a signal was exchanged. It is then trivial to build 
a redemption protocol on top. Note that signaling does 
not require that the value can be arbitrarily chosen by 
C . We will provide a signaling protocol specifically and 
only for bitcoin. Both parts are depicted in Figure 5. 

D. Signaling protocol 

While it is unfeasible for M to monitor the whole dis- 
tributed filesystem, we assume it is feasible for M to mon- 
itor the blockchain. The rationale is that the blockchain 
is small compared to a distributed filesystem because of 



bitcoin's transaction fees. In fact, M does this kind of 
monitoring in any of the before-mentioned protocols, to 
detect incoming payments. Therefore, we carry out the 
signaling protocol over the blockchain. M will be re- 
quired to do work comparable to a full node. 

A specially crafted transaction serves as the signal. 
The requirement is that an observing third party can- 
not distinguish the signaling transaction from a regular 
transaction, in particular i) cannot link the signal to M, 
and ii) cannot read off the signalled value. The under- 
lying idea is to carry out a Diffie-Hellman key exchange 
between M's reputation key P and a pubkey that appears 
in the transaction for which C holds the private key. It 
does not matter whether this second pubkey appears in 
an input or output of the transaction. 

As before, we assume the reputation key P is stored 
on C's trusted path device T. Then C carries out the 
following steps on T: 

1. build an arbitrary transaction X, leaving an arbi- 
trary amount for an output that is to be added, 

2. let a be any pubkey appearing in X, either in an 
input or in an output to a pubkey, 

3. let s be the private key corresponding to a, 

4. let c be the a;-coordinate of the curve point P", 

5. use (iaddr(^', c) as an output address of X. 

The signalled value is c. The curve point = is 
the result of a Diffie-Hellman key agreement between a 
and P. To detect the signal, M carries out the following 
steps for each pubkey a that appears on the blockchain: 

1. let c be the x-coordinate of the curve point a^, 

2. check whether daddr(f', c) is an output address of 
X, if so c is the signalled value. 

In case M denies to have received the signal, C reveals 
the curve point P". This allows anyone to find the signal- 
ing transaction by searching for the address (iaddr(-P, c). 
However, it remains to prove that a given curve point is 
indeed equal to P'^ without revealing s. This is possible 
by providing a certain type of signature [10], which is 
based on a zero-knowledge proof that two discrete log- 
arithms with respect to different bases are equal. The 
signing key is s and the signed message is P. The re- 
sulting signature "proves" that the discrete logarithm of 
P* with respect to basis P equals the discrete logarithm 
of a with respect to basis g (they are both s). C carries 
out the following steps to produce the signature a (cf. 
section 3.2 of [10]). The symbol || means concatenation 
of strings. 

1. choose a random number u, 

2. let V = i?(Pl|P''l|5"l|P"), 

3. let a = (P'^g^^P^'^u + vs). 




FIG. 5. Payment and signaling in one transaction. Suppose of Figure 4 are carried out, these steps are not shown 

here. (T) T appUes address derivation function to contract, obtains payment address. (5) Diffie-HeUman key agreement 
produces shared secret (black key). (5) Transaction is secretly tagged with shared secret. Transaction is signed 

and broadcast to the network. (§) A filename is derived from shared secret, (j) Contract is encrypted with shared 
secret as symmetric key. (8) Ciphertext is posted to distributed filesystem under derived filename. (9) W monitors 
the blockchain and identifies tagged transactions. @ Shared secret is derived from tag. Filename is derived 

from tag and looked up. Data is retrieved and decrypted, W obtains contract. @ W derives payment address 

is derived. @ Order is accepted if payment address equals transaction output. 



A third party verifies a by checking these three equations 
(cf. section 3.2 of [10]): 

V = i?(P||P-'||c,"||P"), = g'^a", P"+"' = P"(P'') 

Note that the signalled value is unique for the pair (P, a). 
This implies that a cannot be used twice for signaling to 
the same P. 

At the end of the protocol, M has control over the 
arbitrary amount that was sent to the output (iaddr(^'i c)- 
As an additional but unused feature, if that output gets 
redeemed on the blockchain then C has a proof that his 
signal was received without revealing P". 



E. Redemption protocol 

To redeem a contract x, C carries out the following 
steps: 

1. signal a unique value c to M, 

2. derive a symmetric key c' from c, e.g. c/ = c or 

c' = H{c), 

3. encrypt x symmetrically with key c' to a;'. 



4. post data x' under the filename H{c') to the dis- 
tributed filesystem. 

When receiving a signal with value c, Af carries out 
the following steps to retrieve the contract: 

1. derive the symmetric key c' from c, 

2. retrieve file x' with filename H{c') 

3. decrypts x' symmetrically with key c' to x 

Redemption is complete, next M looks for a transaction 
with output diiddr{P,x) on the blockchain. 

The signaling and paying protocol can be combined 
into one transaction with two outputs. Since both out- 
puts can be redeemed by M, the funds can be distributed 
arbitrarily between the two outputs. 

F. Signaling variations 

A variation is to use c?addr(a,c) as an output address 
instead of (iaddr(^', c). Then C remains in control of the 
arbitrary amount sent there. However, this has some 
security implications: the private keys of a and c?addr('^j c) 
can be computed from each other by anyone knowing c, 
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e.g. by M. Therefore, after giving the signal, C should 
never separate the private keys of a and (iaddr(a,c), but 
always keep them under the exact same security level. 

V. CONCLUSIONS 

We have introduced a payment protocol for customer- 
merchant relations. Merchants are identified by a public 
key which is their pseudonym. The pseudonym not only 
founds the reputation of the merchant, but it also spec- 
ifies where funds addressed to the merchant are to be 
sent. 

No authenticated or encrypted communication is re- 
quired between customer and merchant, and no signa- 
tures are generated by the merchant at order time. Con- 
sequently, the protocol can work on compromised mer- 
chant infrastructure. The only requirement is that the 
customer possesses a trusted path device, on which all 
sensitive parts of the protocol are concentrated. A one- 
way communication from the payer to the merchant is 
required after the payment, but again security does not 
demand it to be encrypted or authenticated. 

The customer's payment transaction simultaneously 
serves as a receipt for the customer. It proves what has 
been paid for and who received the funds. 

An extension of the protocol allows that all commu- 
nication between customer and merchant is carried out 
openly via a distributed filesystem. In this way the mer- 
chant can hide all his infrastructure from the customer 
and stay truly pseudonymous. 

The protocol is suitable for bitcoin as the underlying 
payment system. Since bitcoin transactions are pub- 
licly recorded, the protocol allows to exchange funds and 
receipt in an atomic transaction. Despite this public 
record, transactions cannot be linked to the merchant 
pseudonym by third-party observers. 

An implementation with bitcoin would require little ef- 
fort. One requirement is the standardization of the "la- 



beled wallets" that we introduced, and their implemen- 
tation across all bitcoin clients. A second requirement 
is an authentication infrastructure for the merchant's 
pseudonyms, preferably inside the bitcoin client. Since 
pseudonyms are equivalent to bitcoin addresses, the cus- 
tomer can simply tag those bitcoin addresses which are 
pseudonyms of merchants that he has started a business 
relation with. To use all features of the protocol, how- 
ever, pseudonyms are to be distributed via a public key 
infrastructure or web-of-trust. 

Hardware wallets, which are currently under develop- 
ment, can serve as the trusted path device for the cus- 
tomer. The requirement is that a bitcoin client with the 
above mentioned additional features is running on the 
hardware wallet. Also the hardware wallet is required to 
be able to display a considerable amount of text. 
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